\chapter{Cahier des charges}
Il faut maintenant définir les différents besoins ainsi que des scénariostc afin de mettre en place une implémentation la plus proche possible du vrai mécanisme. Cette deuxième illustration (figure \ref{spa2}) montre bien que SPA est la première barrière rencontrée lors d'un accès à un service, et c'est bien lui qui autorise ou non l'accès au service par l'intermédiaire du pare-feu (firewall sur le schema).
\begin{figure}[!h]
\begin{center}
\includegraphics[scale=0.7]{utils/spa2.png} 
\end{center}
\caption{\label{spa2}Schéma d'accès par couche à un service\cite{Un}}
\end{figure}
\section{Besoins fonctionnels}
\subsection{Forger un paquet}
Le premier objectif à implémenter est la creation d'un paquet et l'envoi de celui ci. Cette partie est la base du projet, tout le reste repose sur son implémentation. Le noyau Linux utilise la bibliothèque libnet\cite{Schiffman} pour forger et envoyer des paquets, ce qui va faciliter le travail de cette implémention, en utilisant les fonctions proposées par cette bibliothèque. Du coté serveur il faut mettre en place un mécanisme d'écoute active du réseau afin de permettre la récupération des paquets concernés. La bibliothèque libpcap\cite{Garcia} propose justement des fonctions paramètrables, pour instaurer ce mécanisme. Enfin le serveur doit désencapsuler le paquet pour extraire les données. Il faut donc utiliser les bibliothèques permettant de récupérer les en-têtes du modèle TCP/IP (ip, udp, ethernet).  

\subsection{Authentification, cryptage et codage}
Cette étape est une phase cruciale de ce projet. En effet elle permet d'authentifier, de crypter et coder un message afin de prévenir tout risque de lecture de celui-ci en cas d'interception par une tierce personne. Linux utilise libmcrypt et libmhash pour crypter et hacher un paquet. Celles-ci vont donc être utilisées pour générer un paquet optimal pour l'envoi. En ce qui conrcerne le codage il suffit d'implémenter une fonction qui transforme une chaine de caractère en une suite de mots simples (mot contenant des caractères non exotiques). Du coté serveur, il doit être capable de décrypter et de décoder un message et de pouvoir l'authentifier.
\subsection{Mécanismes sécuritaires}
Afin de répondre à des questions d'intégrités de données et de services auxquels l'utilisateur souhaite accéder, les mécanismes de sécurité sont primordiaux. Le serveur doit détecter les paquets rejoués à travers une structure de sauvegarde dynamique d'anciens paquets. De plus il doit différencier les paquets légitimes des paquets périmés (par exemple un paquet forgé à un temps T et envoyé à un temps T+1000 est périmé).
\subsection{Intéraction avec le pare-feu}
La dernière étape consiste à implémenter un module de création et d'insertion de règles dans le pare-feu. SPA autorise l'accès à des services mais seulement durant un intervalle de temps donné. Donc il faut intégrer une notion de durée dans l'implémentation. Pour cela une alarme est nécessaire. Elle indique au pare-feu si les règles qu'il possède doivent être maintenues actives ou non. L'insertion de règles se fait par l'intermédiaire d'appels systèmes.
\section{Besoins non-fonctionnels}
Ce programme etant un mecanisme sécuritaire il doit fonctionner dans le maximum d'environnements possible, ce qui implique qu'il doit posséder certaines qualités.
\subsection{Performance}
Ce mécanisme fonctionne en arrière plan du système d'exploitation, ce qui veut dire qu'il démarre lors du lancement de l'OS et s'arrête en même temps. Donc il doit être performant pour assurer l'accès aux services durant son temps d'exécution, qui soit dit en passant, peut être très long.  En effet si il n'est pas performant et s'arrête ou bien augmente son temps de calcul par message, il peut fortement ralentir l'accès aux ressources, voire même empêcher de consulter celles-ci. 
\subsection{Fiabilité}
La fiabilité est un point essentiel dans la mise en place de ce programme. Un paquet envoyé par un client doit être décrypté correctement ainsi que décodé et authentifié. Si une de ces étapes n'est pas fiable alors le paquet ne sera pas traité dans tous les cas et donc l'utilisateur légitime n'aura pas accès aux services demandés à chaque fois. 
\subsection{Sécuritaire}
Ce programme a pour but d'assurer l'intégrité des services qu'il protège. Pour cela il doit contenir des notions de sécurité afin d'empêcher au maximum les intrusions par un attaquant. l'implémentation et le maintient de ces mécanismes est primordial pour sécuriser le lien ainsi que les données entre un utilisateur et un service.
\subsection{Transparence}
La transparence est un point important de ce projet. L'utilisateur ne doit pas voir ce qui se passe en arrière plan du programme. Pour lui ce doit être une simple demande d'accès à des services, qu'il inscrit après demande dans le terminal de commande. Cette condition rend par ailleur le programme utilisable aisément pour un utilisateur lambda.
\subsection{Langage de programmation}
Le langage de programmation utilisé est le C. Celui-ci permet notamment d'utiliser les bibliothèques citées précédemment (libnet, libmcrypt etc...). De plus il autorise le contrôle de la gestion de la mémoire, ce qui est inmportant surtout lors de la manipulation de chaînes de caractères.
\section{Scénarios}
Les scénarios vont permettre de cadrer le projet dans un environnement particulier, pour ensuite pouvoir réaliser une batterie de tests en accord avec les différentes mise en situation. Les deux scénarios peuvent se réaliser simultanément ou indépendament l'un de l'autre.
\subsection{Environnement}
L'environnement défini pour instaurer les scénarios est le suivant :
\begin{itemize}
\item Deux clients (un légitime et l'autre non) + un serveur
\item Ces trois entités sont dans le même sous-réseau
\item Ce réseau est filaire
\item Le pare-feu du serveur est déja configuré de manière adéquate
\item Le serveur partage déjà un secret avec chacune des deux machines
\end{itemize}
\subsection{Premier cas}
Le premier scénario utilise uniquement le client légitime. Cette machine doit forger un paquet avec une liste de services à laquelle elle souhaite accéder. Une fois le paquet construit il est envoyé au serveur. L'objectif de ce premier cas est de mettre en évidence la fiabilité du système, montrer que la phase de cryptage/décryptage ainsi que la phase de codage/décodage fonctionnent à chaque réception de message. Voici maintenant les phases point par point de ce scénario du côté client.
\begin{itemize}
\item Forger un paquet en demandant un accès au port ssh (port 22)
\item Se connecter en ssh sur le port précisé pour vérifier que la demande a bien été prise en compte
\item Attendre une dizaine de secondes tout en restant connecté et vérifier que la connexion est toujours établie
\item Se déconnecter et réessayer de se connecter comme précédemment afin de montrer que la règle a bien été supprimée par le pare-feu

\end{itemize}
\subsection{Deuxième cas}
Ce deuxième scénario met en évidence un autre point important de ce projet : la sécurité. Cette notion est mise en avant grâce au client illégitime. En effet celui-ci est programmé pour envoyer plusieurs fois le même paquet (T=0, T=3, T=40), ce qui permet d'activer le mécanisme anti-rejeu. Le premier paquet doit être accepté par le serveur alors que les deux suivants non. 
